home *** CD-ROM | disk | FTP | other *** search
/ Hackers Handbook - Millenium Edition / Hackers Handbook.iso / library / hack99 / anatomy.of.attack.txt < prev    next >
Encoding:
Internet Message Format  |  1999-03-24  |  5.0 KB
  1. Date: Sun, 14 Mar 1999 14:34:29 -0700 (MST)
  2. From: mea culpa <jericho@dimensional.com>
  3. To: InfoSec News <isn@repsec.com>
  4. Subject: [ISN] Anatomy of a fairly easy attack
  5.  
  6.  
  7. >From: Subash Raman <subash@hotmail.com>
  8.  
  9. An anatomy of a fairly easy attack
  10.  
  11. Once upon a time, an auditor was asked to prove that an organizations
  12. machines are not insecure. Their lamentable naivete notwithstanding, the
  13. auditor got them to sign the necessary legalese and then turned his
  14. attention to the task at hand. Some background for those who like their
  15. detail It was an NT environment with SQL Server 6.5 So our hero starts his
  16. venture by first running a tool called chronicle which tells him what
  17. service packs are running on which servers. That eliminates a lot of
  18. unnecessary probing for vulnerabilities does it not. When he realised that
  19. they are only running SP-3 and no other patches have been applied and
  20. furthermore on realising that they are using SMS (client server network
  21. management s/w)  he uses sechole (easily obtainable from the net) and gets
  22. in as a domain admin from a lowly regular account. 
  23.  
  24. Their PDC turned out to be fairly easy since their registries were
  25. unprotected He next ran a find and lo and behold found two default
  26. accounts with passwords scripted in the registry. Next using these
  27. accounts he attached to their shares (hidden of course only redbutton had
  28. no trouble finding them)  and then proceeded to download the SAM's and
  29. what's of more interest the drwtsn32.log file. 
  30.  
  31. Sadly the log file didn't contain much interesting data of the variety he
  32. was after but he did glean from them an internal webserver that was
  33. accessing them. So back to info gathering he scanned the entire network
  34. and picked up the webservers. A few quick perlscripts (and a very nifty
  35. tool called the grinder which can recursively go through the urls
  36. automatically) and he nailed the server he was after. Using the datastream
  37. technique he managed to get hold of the source code for the asp scripts
  38. esp. global.asa and lo and behold the connection objection had the userid
  39. and password for their sqlserver right there. In a matter of minutes he
  40. was inside the server again with isql getting the creditcard information
  41. he had been challenged to find. 
  42.  
  43. redbutton, grinder, couple of perlscripts to parse through the data,
  44. whatsup gold to do network maps (and portscans) and he was inside
  45. literally the corporate data vault in a matter of a couple of hours. 
  46.  
  47. If he was a real hacker and he didn't have access to a webserver using ASP
  48. code, he could have still done it by <you guessed it> running a
  49. particularly nasty DOS attack to bring the SQL Server crashing down and
  50. then going through the log. Dumpster diving is not considered very
  51. glamourous but you will agree that most insider hacking is based on
  52. examining core dumps by knowledgeable debuggers. In the case of the NT
  53. logs you don't even need to know how to core analysis, all you have to
  54. know is english and have enough patience to keep going through them till
  55. you find the info you are looking for. 
  56.  
  57. Since he was inside SQL Server with sa privileges he ran xp_shellcmd and
  58. added himself as a user and then proceeded to add the id to the global
  59. domain admins group as well just to make a long story short. 
  60.  
  61. Why did I do this anatomy of a typical attack ? And what are the dangers
  62. of teaching people such methods ? 
  63.  
  64. Lots generally, but to tell you the truth if somebody had spend some time
  65. cleaning up the registries, applying the key post sp-3/sp-4 hotfixes and
  66. then ensured strict compliance with policies such as no clear text
  67. scripting when it came to coding and removal of stored procedures such as
  68. xp_cmdshell with more specific stored procedures then it would have been
  69. far more difficult to have done what I did. and the tools i mentioned can
  70. be got off the internet very, very easily. So you are definitely not
  71. underestimating the dangers when you warn people.  I just felt that it is
  72. also necessary to further prove the point by writing this article of how
  73. somebody would actually go about doing it. 
  74.  
  75. Hope this enlightens more than it obfuscates. Have to admit that this note
  76. coming at the end of a day spent trying to establish the need for both
  77. policy, awareness and a protection strategy that pays equal attention to
  78. prevention, detection, reaction and alleviation is probably why I decided
  79. to break my usual silence on this matter and come out in the open about
  80. this. Plus I am beginning to feel that we are fighting a losing battle
  81. trying to raise awareness and are being drowned by the focus on the media
  82. driven threats as opposed to the real ones. Oh well, maybe I'll go back to
  83. doing budget management. At least forecasting models are a lot less dicier
  84. to deal with than security issues. 
  85.  
  86. regds,
  87. -sr
  88.  
  89. P.S. and don't ask me for the name of the poor auditor. he's far too busy
  90. to have the time to answer your questions and he's far too modest to want
  91. to relinquish his identity and come out of the closet anyway <grin>
  92.  
  93.  
  94. -o-
  95. Subscribe: mail majordomo@repsec.com with "subscribe isn".
  96. Today's ISN Sponsor: Internet Security Institute [www.isi-sec.com]
  97.  
  98.  
  99.